Cits

Motto

"The studies of Philosophy is not about reciting Books, it's about arguing 'strictly'." (Although the former might proof helpful it can never be sufficient)

"... saying what others have thought, it's about saying what you think." (and thinking about what you say! (and therefore thinking about what others have thougt))

"..., it's about thinking what you are going to say"

Some favourite party lines

"Whereof one cannot speak, thereof one must be silent." Ludwig Wittgenstein

"The concepts induced by a formal context form a complete lattice." Rudolf Wille (basic theorem of Formal Concept Analysis)

"There is no Ignorabimus." David Hilbert (although it's wrong)

Elementary Equivalence

Definition Elementary Equivalence of Structures

Let ${\mathfrak {A}}$ and ${\mathfrak {B}}$ be S-Structures. ${\mathfrak {A}}$ and ${\mathfrak {B}}$ are said to be Elementary Equivalent (short: ${\mathfrak {A}}\equiv {\mathfrak {B}}$ ) iff for all S-Sentences φ it is

{\mathfrak {A}}\vDash \varphi

iff

{\mathfrak {B}}\vDash \varphi

.

Isomorphism

Definition Isomorphism on Structures and Isomorphic Structures

Let ${\mathfrak {A}}$ and ${\mathfrak {B}}$ be S-Structures. A mapping $p:A\to B$ is said to be an Isomorphism from ${\mathfrak {A}}$ to ${\mathfrak {B}}$ (short: p: ${\mathfrak {A}}\cong {\mathfrak {B}}$ ) iff all of the following conditions hold:

p is a bijection from $A$ to $B$
for n-ary $R\in S$ it is
$R^{\mathfrak {A}}a_{1},...,a_{n}\iff R^{\mathfrak {B}}p(a_{1}),...,p(a_{n})$
for n-ary $f\in S$ it is
$p(f^{\mathfrak {A}}(a_{1},...,a_{n}))=a\iff f^{\mathfrak {B}}(p(a_{1}),...,p(a_{n}))=p(a)$
for $c\in S$ it is
$p(c^{\mathfrak {A}})\iff c^{\mathfrak {B}}$

with $a_{1},...,a_{n};a\in A$ .

${\mathfrak {A}}$ and ${\mathfrak {B}}$ are said to be isomorphic (short: ${\mathfrak {A}}\cong {\mathfrak {B}}$ ) iff there exists an isomorphism from ${\mathfrak {A}}$ to ${\mathfrak {B}}$ .

Lemma Elementary Equivalence in Isomorpic Structures

Let ${\mathfrak {A}}$ and ${\mathfrak {B}}$ be S-Structures. It is

if

{\mathfrak {A}}\cong {\mathfrak {B}}

then

{\mathfrak {A}}\equiv {\mathfrak {B}}

.

The inverse is not the case, i.e. elementary equivalent S-Structures are not isomorphic in general.

Isomorphy in infinite Elementary Equivalent Structures

In order to show that elementary equivalence does not generally imply isomorphy, consider the Peano Arithmetic, as given by the following axioms:

$\forall x(Sx\neq 0).$
$\forall x,y((Sx=Sy)\Rightarrow x=y).$
$(\varphi [0]\wedge \forall x(\varphi [x]\Rightarrow \varphi [Sx]))\Rightarrow \forall x(\varphi [x]),$ for any formula $\varphi$ in the language of PA.
$\forall x(x+0=x).$
$\forall x,y(x+Sy=S(x+y)).$
$\forall x(x\cdot 0=0).$
$\forall x,y(x\cdot Sy=(x\cdot y)+x).$

Now consider N(+, *) as model A. In order to construct an elementary equivalent but not isomorphic model simply add an element a that is not yet in N. To satisfy axiom 3 we also have to add successors and predecessors starting from a. For satisfying axioms 4 to 7 the results of addiotions and multiplications of the new elements have to be added as well. So, finally we have constructed a non-isomporphic model for A that obeys all the above axioms.

Notice that this can not be done with the peano axioms, since axiom 3 ist stricter there, i.e. it is about the set of all natural numbers not just of some, as the above is.

Formalising the above leads to the following theorem:

Skolem Theorem

There is a non-standard model of arithmetic,

where 'non-standard' means elementary equivalent but nor isomorphic.

But it gets even worse:

Theorem

For every infinite structure there is a elementary equivalent and non-isomorphic structure.

We omit any proof or explaination here. This leaves us with the case of finite structures, to find out how elementary equivalence and isomorphy relate there.

Isomorphy in finite Elementary Equivalent Structures

Theorem

For finite relational structures ${\mathfrak {A}}$ and ${\mathfrak {A}}$ it is

{\mathfrak {A}}\cong {\mathfrak {B}}

iff

{\mathfrak {A}}\equiv {\mathfrak {B}}

.

Proof

"=>" follows immediately from the general case.

"<=": First, we construct a sentence to describe every possible structure generically

The number of elements of the universe can precisely be expressed by the following:
- ..., says that there are at least n elements in the universe
- ..., says that the universe contains at most n elements
Any relation in the language can be described by describing it element by element
- $Rx_{1},...,x_{n}$ , in case ...
- $\neg Rx_{1},...,x_{n}$ , in case ...
Constants can be mapped by
- ...
Not to forget the equivalence relation, we add
- ...

Alltogether (by conjunction) we get a up to isomorphism unique structure. To see this, compare to the definition of isomorphy: relations and constants are determined entirely and the bijectivity is insured by the fixed number of elements.

UML Tool

One can think of an UML-Tool as a databasesystem keeping a model. The structure of the database is given by the UML meta model and all the Use Cases, Classes, Relations etc of the Model are it's entries. As with every DB-application the very basic functionality of an UML tool is to create, read, update or delete these entries in a consistent way. The means of doing this are Diagrams (as defined in UML and probably additional ones). They provide views to the model. (The difference between model and diagram is often confused by users). In diagrams parts of a model are presented: displaying the model in it's concrete syntax and providing navigation and information capabilities, like jumping to a representation of the selected element in another diagram etc. edited: crud of model elements and their relations and properties, like adding a use case to a use case diagram, relate it to an actor and writing a textual description of it's behaviour. verified: keeping the model consistend at editing time (e.g. when an element is deleted by the user it's binary relations are deleted as well by the tool) and subsequently by model checking (e.g. ensuring every state machine has one entry point)

So far the benefit of UML-tools is visualising models (and thus improving communication, easing abstracion etc). But moreover a properly specified model can be leveraged by generating source code from it. So code generation is a very important (i.e. efficiency increasing) feature of most UML-tools. Actually the term 'generation' is sligthly misleading since it refers not only to the initial creation of the sources but also to keeping them up-to-date with the model for the case of changes in the model as well as in the code. Here different policies of dealing with these differences can be applied (-> code generation) Often UML modelling is applied not only to new projects but also to already running developments. Here it is important to be able to generate a model initially from existing sources, the so called reverse engineering. In order to provide seamless working on the coding and modelling level many UML-tools provide front-end integration with the most common IDEs.

TODO Multi-Models: Profiles

Since modelling in a development project often consists of multiple models, like analysis and design model, it is important to keep track of the dependencies between these models. UML-tools usually provide means of doing this. On the low-end by references (links) that can be set by the user. On the high-end by model-to-model transformations, that can be defined and executed in the UML-tool. The latter can be thought of similarly to code generation, but keeping 2 models consistent intead of a model and some source code.

Information in development project usually is not only kept in uml models but also in requirements tools, office documents, test tools, tracking tools etc. Therefore it is important to be able to integrate with all the tools such that model information can be provided and other information can be read. Also exchange between different UML-tools must be provided. This can be done by exporting/ importing to/ from the XMI format.

Modelling may it be for analysis, design or other purposes usually is part of a whole software development process. Thus UML-tools must be able to be integrated in the project's workflows and management. Therefore, like other tools as well, they must be able to generate documents from the models, support workflow definitions (like setting the status of a component to 'under_revision' etc), extract baselines, create versions and variants, monitor the progress, define user roles and access rights, handle access conflicts, generate query based reports etc.

License tagging for File:Math graph nikos house 01.gif

Thanks for uploading File:Math graph nikos house 01.gif. You don't seem to have indicated the license status of the image. Wikipedia uses a set of image copyright tags to indicate this information; to add a tag to the image, select the appropriate tag from this list, click on this link, then click "Edit this page" and add the tag to the image's description. If there doesn't seem to be a suitable tag, the image is probably not appropriate for use on Wikipedia.

For help in choosing the correct tag, or for any other questions, leave a message on Wikipedia:Media copyright questions. Thank you for your cooperation. --ImageTaggingBot (talk) 15:05, 17 February 2011 (UTC)[reply]

Image tagging for File:Math graph nikos house 04.gif

Thanks for uploading File:Math graph nikos house 04.gif. You don't seem to have said where the image came from or who created it. We require this information to verify that the image is legally usable on Wikipedia, and because most image licenses require giving credit to the image's creator.

To add this information, click on this link, then click the "Edit" tab at the top of the page and add the information to the image's description. If you need help, post your question on Wikipedia:Media copyright questions.

For more information on using images, see the following pages:

Thank you for your cooperation. --ImageTaggingBot (talk) 19:06, 17 February 2011 (UTC)[reply]